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We  argue  that  the  ability  to  model  shared  objects  with  changing 
local  states,  dynamic  reconfigurability,  and  inherent  parallelism  are 
desirable  properties  of  any  model  of  concurrency.  The  actor  model 
addresses  these  issues  in  a  uniform  framework.  This  paper  briefly  de¬ 
scribes  the  concurrent  programming  language  Acts  and  the  principles 
that  have  guided  its  development.  ActS  advances  the  state  of  the 
art  in  programming  languages  by  combining  the  advantages  of  object- 
oriented  programming  with  those  of  functional  programming.  We  also 
discuss  considerations  relevant  to  large-scale  parallelism  in  the  context 
of  open  systems,  and  define  an  abstract  model  which  establishes  the 
equivalence  of  systems  defined  by  actor  programs. 


The  report  describes  research  done  at  the  Artificial  Intelligence  Laboratory 
of  the  Massachusetts  Institute  of  Technology.  Support  for  the  laboratory’s 
artificial  intelligence  research  is  provided  in  part  by  the  the  System  Develop¬ 
ment  Foundation  and  in  part  by  the  Advanced  Research  Projects  Agency  of 
the  Department  of  Defense  under  Office  of  Naval  Research  contract  N0014- 
80-C-0505.  The  authors  acknowledge  helpful  comments  from  Fanya  Mon¬ 
talvo,  Carl  Manning  and  Tom  Reinhardt. 


o  f-ir.Str.IUSFTT5  :::ST;7T:  TiCPXOlOGY 
l  Thr,  do  hoD  b ~  ■>  'JPJ 


■M 


toi  r  .>  •  ° 

V  ,  ...  ..!!'•  '*■ 


85  i  - 


034 


'„‘i| 

2 

II 


UNCLASSIFIED 


S£CU»lTv  ClASS'FicATiqn  Or  TmiS  PAGE  rwhtn  Dm it  Cnlmtmd) 


REPORT  DOCUMENTATION  PAGE 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


»•  RECIPIENT'S  catalog  number 


4.  TITLE  <*\d  Subtttli) 


%■  TYRE  OF  REPORT  *  PERIOD  COVERED 


Concurrent  Programming  Using  Actors:  Exploiting 
Large  Scale  Parellism  I 


•  RERroRMINC  ORG.  REPORT  NUMBER 


OnTracT  or  grant  MUMBERft; 


N0014-80-C-0505 


»  PERFORMING  ORGANIZATION  NAME  ANO  AOORESS 

Artificial  Inteligence  Laboratory 
545  Technology  Square 
Cambridge,  MA  02139 


■  I.  CONTROLLING  OFFICE  NAME  ANO  AOORESS 

Advanced  Research  Projects  Agency 
1400  Wilson  Blvd. 

Arlington,  VA  22209 


14  MONITORING  agency  NAME  A  AOORESSfff  dlltmrmnt 

Office  of  Naval  Research 
Information  Systems 
Arlington,  VA  22217 


la.  OECLASSIFICATION/OORNGRAOING 

schedule 


19-  KEY  WORDS  (CriIIini#  mi  II  m  iMnnfr  *7  W#e k 

Concurrency  Actors 

Distributed  Computing  Functional  Programming 

Programming  Languages  Parellel  Processing 

Object-Oriented  Programming  Open  Systems 


10.  ABSTRACT  (Can IMma  an  raaaraa  >Mt  II  naaaaaar y  mt*  Manlllr  Ay  MacA  —In) 

We  argue  that  the  abilty  to  modle  shaared  objects  with  changing  local  states 
dynamic  reconf igurabilty ,  and  inherent  parellism  are  desirable  properties  of 
any  model  of  concurrency.  The  actor  model  addresses  these  issues  in  a 
uniform  framework.  This  paper  briefly  describes  the  concurrent  programming 
language  Act3  and  the  principles  that  have  guided  its  development.  Act3  ad¬ 
vances  the  state  of  theart  inprogramming  languages  by  combining  the  advan¬ 
tages  of  object-oriented  programming  with  those  of  functional  programming. 
We  also  discuss  considerations  revelant  to  the  large  scale  narellism  in  the 
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1  Background 

The  theory  of  concurrent  programming  languages  has  been  an  exciting  area 
of  research  in  the  last  decade.  Although  no  consensus  has  emerged  on  a 
single  model  of  concurrency,  many  advances  have  been  made  in  the  develop¬ 
ment  of  various  contending  models.  There  have  also  been  some  consistent 
paradigm  shifts  in  the  approach  to  concurrency;  an  interesting  discussion  of 
such  paradigm  shifts  may  be  found  in  [Pratt  83]. 

The  actor  model  of  computation  has  developed  contemporaneously  in 
the  last  decade  along  with  other  models  based  on  Petri  Nets,  the  A-calculus, 
and  communicating  sequential  processes.  There  has  been  a  great  deal  of 
useful  cross  fertilization  between  the  various  schools  of  thought  in  address¬ 
ing  the  very  difficult  issues  of  concurrent  systems.  Over  the  years  Hoare, 
Kahn,  MacQueen,  Milner,  Petri,  Plotkin,  and  Pratt,  have  provided  fruitful 
interaction  on  the  development  of  the  actor  model. 

Landin  [65]  first  showed  how  Algol  60  programs  could  be  represented  in 
applicative-order  A-calculus.  Kahn  and  MacQueen  [77]  developed  this  area 
further  by  expanding  on  the  construct  of  streams  which  captured  functional 
systems.  Brock  and  Ackerman  [77]  extended  the  Kahn-MacQueen  model 
with  the  addition  of  inter-stream  ordering  information  in  order  to  make  it 
more  suitable  for  concurrent  computation.  Pratt  [82]  generalized  the  func¬ 
tional  model  by  developing  a  theory  of  processes  in  terms  of  sets  of  partially 
ordered  multisets  ( pomsets )  of  events.  Each  pomset  in  Pratt’s  Process  Model 
represents  a  trace  of  events.  Pratt’s  model  satisfies  several  properties  de¬ 
sirable  in  any  model  of  concurrent  computation.  For  example,  the  model 
does  not  assume  the  existence  of  global  states:  a  trace  is  only  a  partial 
order  of  events.  Thus  the  model  is  compatible  with  the  laws  of  parallel  pro¬ 
cessing  formulated  in  [Hewitt  and  Baker  77]  and  shown  to  be  consistent  in 
[Clinger  81]. 

On  the  practical  side,  McCarthy  [59]  first  made  functional  programming 
available  by  developing  LISP.  The  standard  dialect  of  LISP  now  incorpo¬ 
rates  lexical  scoping  and  closures  which  makes  the  semantics  simpler  and 
programming  modular  [Steele,  et  al  84],  Acts  generalizes  the  lexical  scop¬ 
ing  and  upward  closures  of  LISP  in  the  context  of  parallel  systems. 

Hoare  [78]  proposed  a  language  for  concurrency,  called  CSP,  based  on 
sequential  processes.  CSP,  like  ActS,  enhances  modularity  by  not  permit¬ 
ting  any  shared  variable  between  processes;  instead,  communication  is  the 
primitive  by  which  processes  may  affect  each  other.  At  a  more  theoretical 
level,  Milner  [80]  has  proposed  the  Calculus  of  Concurrent  Systems  (CCS). 
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One  of  the  nice  properties  of  CCS  is  its  elegant  algebraic  operations.  In 
both  CSP  and  CCS ,  communication  is  synchronous  and  resembles  a  hand¬ 
shake.  In  contradistinction,  the  actor  model  postulates  the  existence  of  a 
mail  system  which  buffers  communication. 

The  plan  of  this  paper  is  as  follows:  the  first  section  outlines  the  actor 
model.  The  second  section  describes  the  AetS  language.  The  final  section 
discusses  the  general  principles  of  open  systems  and  there  relation  to  the 
actor  model. 


2  The  Actor  Model 

In  this  section  we  motivate  the  primitives  of  the  actor  model.  We  will  outline 
the  basic  issues  and  describe  a  set  of  minimal  constructs  necessary  for  an 
actor  language. 

2.1  Foundational  Issues 

A  number  of  difficult  open  problems  and  foundational  issues  in  the  design  of 
programming  languages  for  concurrent  systems  merit  attention.  We  consider 
the  following  three  significant: 

1.  Shared  Resources.  The  programming  model  must  deal  with  the 
problem  of  shared  resources  which  may  change  their  internal  state. 
A  simple  example  of  such  an  object  in  a  concurrent  environment  is  a 
shared  bank  account.  Purely  functional  systems,  unlike  object-based 
systems,  are  incapable  of  implementing  such  objects  [Hewitt,  et  al  84]. 

2.  Dynamic  Reconfigurability.  The  programming  model  must  deal 
with  the  creation  of  new  objects  in  the  evolution  of  the  system.  In 
particular,  to  accommodate  the  creation  of  new  objects,  there  must 
be  a  mechanism  for  communicating  the  existence  of  such  new  objects 
(or  processes)  to  already  existing  ones.  Thus  when  a  bank  creates  a 
new  account,  it  should  be  able  to  inform  its  book-keeping  process  of 
the  existence  of  such  an  account.  Since  the  interconnection  topology 
of  processes  is  static  in  systems  such  as  CSP  and  dataflow  [Brock  83], 
this  requirement  is  necessarily  violated  these  systems. 

3.  Inherent  Parallelism.  The  programming  model  should  exhibit  in¬ 
herent  parallelism  in  the  sense  that  the  amount  of  available  concur- 
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rency  should  be  clear  from  the  structure  of  programs.  It  should  not 
be  necessary  to  do  extensive  reasoning  to  uncover  implicit  parallelism 
that  is  hidden  by  inappropriate  language  constructs.  In  particular,  the 
assignment  command  is  a  bottleneck  inherited  from  the  vcn  Neumann 
architecture.  Assignment  commands  tie  the  statements  in  the  body  of 
a  code  in  such  a  way  that  only  through  flow  analysis  is  it  possible  to 
determine  which  statements  can  be  executed  concurrently.  Functional 
Programming  has  the  advantage  of  being  inherently  parallel  because 
it  allows  the  possibility  of  concurrent  execution  of  all  subexpressions 
in  a  program  [Backus  78]. 

The  object-based  and  functional,  A-calcuIus-based  languages  represent 
two  of  the  most  important  schools  of  thought  in  programming  language  the¬ 
ory  today.  As  the  above  discussion  suggests,  both  have  certain  advantages. 
AetS  attempts  to  integrate  both  in  a  manner  that  preserves  some  of  their 
attractive  features. 


2.2  Basic  Constructs 

The  actor  abstraction  has  been  developed  to  exploit  message-passing  as  a 
basis  for  concurrent  computation  [Hewitt  77;  Hewitt  and  Baker  77].  The 
actor  construct  has  been  formalized  by  providing  a  mathematical  definition 
for  the  behavior  of  an  actor  system  [Agha  85].  Essentially,  an  actor  is  a 
computational  agent  which  carries  out  its  actions  in  response  to  processing 
a  communication.  The  actions  it  may  perform  are: 

•  Send  communications  to  itself  or  to  other  actors. 

•  Create  more  actors. 

•  Specify  the  replacement  behavior. 


In  order  to  send  a  communication,  the  sender  must  specify  a  mail  ad¬ 
dress,  called  the  target.  The  mail  system  buffers  the  communication  until  it 
can  be  delivered  to  the  target.  However,  the  order  in  which  the  communica¬ 
tions  are  delivered  is  nondeterministic.  The  buffering  of  communications  has 
the  consequence  that  actor  languages  support  recursion.  In  languages  re¬ 


lying  on  synchronous  communication,  any  recursive  prnrediire  immediately^ 
leads  to  deadlock  [Hewitt,  et  al  1984]  [Agha  1985].  I  I  1  [ 
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All  actors  have  their  own  (unique)  mail  addresses  which  may  be  commu¬ 
nicated  to  other  actors  just  as  any  other  value.  Thus  mail  addresses  provide 
a  simple  mechanism  for  dynamically  reconfiguring  a  system  of  actors.  The 
only  way  to  affect  the  behavior  of  an  actor  is  to  send  it  a  communication. 
When  an  actor  accepts  a  communication,  it  carries  out  the  actions  specified 
by  its  behavior;  one  of  these  actions  is  to  specify  a  replacement  actor  which 
will  then  accept  the  next  communication  received  at  the  mail  address. 

Two  important  observations  need  to  be  made  about  replacement.  First, 
replacement  implements  local  state  change  while  preserving  referential  trans¬ 
parency  of  the  identifiers  used  in  a  program.  An  identifier  for  an  object 
always  denotes  that  object  although  the  behavior  associated  with  the  ob¬ 
ject  may  be  subject  to  change.  In  particular,  the  code  for  an  actor  does 
not  contain  spurious  variables  to  which  different  values  are  assigned  (see 
[Stoy  77]  for  a  thorough  discussion  of  referential  transparency).  Second, 
since  the  computation  of  a  replacement  actor  is  an  action  which  may  be 
carried  out  concurrently  with  other  actions  performed  by  an  actor,  the  re¬ 
placement  process  is  intrinsically  concurrent.  The  replacement  actor  cannot 
affect  the  behavior  of  the  replaced  actor. 

The  net  result  of  these  properties  of  replacement  actors  is  that  compu¬ 
tation  in  actor  systems  can  be  speeded-up  by  pipelining  the  actions  to  be 
performed.  As  soon  as  the  replacement  actor  has  been  computed,  the  next 
communication  can  be  processed  even  as  other  actions  implied  by  the  cur¬ 
rent  communication  are  still  being  carried  out.  In  actor-based  architectures, 
the  only  constraints  on  the  speed  of  execution  stem  from  the  logical  depen¬ 
dencies  in  the  computation  and  the  limitations  imposed  by  the  hardware 
resources.  In  von  Neumann  architectures,  the  data  dependencies  caused  by 
assignments  to  a  global  store  restrict  the  degree  of  pipelining  (in  the  form 
of  instruction  pre-fetching)  that  can  be  realized  [Hwang  and  Briggs  84]. 

AH  actors  in  a  system  carry  out  their  actions  concurrently.  In  partic¬ 
ular,  this  has  the  implication  that  message-passing  can  be  used  to  spawn 
concurrency:  An  actor,  in  response  to  a  communication,  may  send  several 
communications  to  other  actors.  The  creation  of  new  actors  also  increases 
the  amount  of  parallelism  feasible  in  a  system.  Specifically,  continuations 
can  be  incorporated  as  first-class  objects.  The  dynamic  creation  of  cus¬ 
tomers  in  actor  systems  (discussed  later)  provides  a  parallel  analogue  to 
such  continuations. 
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2.3  Transitions  on  Configurations 

To  describe  an  actor  system,  we  need  to  specify  several  components.  In 
particular,  we  must  specify  the  behaviors  associated  with  the  mail  addresses 
internal  to  the  system.  This  is  done  by  specifying  a  local  states  function 
which  basically  gives  us  the  behavior  of  each  mail  address  (i.e.,  its  response  to 
the  next  communication  it  receives).  We  must  also  specify  the  unprocessed 
communications  together  with  their  targets.  The  communication  and  target 
pairs  are  referred  to  as  tasks.  A  configuration  is  an  instantaneous  snapshot  of 
an  actor  system  from  some  viewpoint.  Each  configuration  has  the  following 
parts: 


•  A  local  states  function  which  basically  gives  us  the  behavior  of  a  mail 
address.  The  actors  whose  behaviors  are  specified  by  the  local  states 
function  are  elements  of  the  population. 

•  A  set  of  unprocessed  tasks  for  communications  which  have  been  sent 
but  not  yet  accepted. 

•  A  subset  of  the  population,  called  receptionist  actors,  which  may  re¬ 
ceive  communications  from  actors  outside  the  configuration.  The  Bet  of 
receptionists  can  not  be  mechanically  determined  from  the  local  states 
function  of  a  configuration:  it  must  be  specified  using  knowledge  about 
the  larger  environment. 

•  A  set  of  external  actors  whose  behavior  is  not  specified  by  the  local 
states  function,  but  to  whom  communications  may  be  sent. 

A  fundamental  transition  relation  on  configurations  can  be  defined  by 
applying  the  behavior  function  of  the  target  of  some  unprocessed  task  to 
the  communication  contained  in  that  task  (see  the  definition  below).  Given 
the  nondeterminism  in  the  arrival  order  of  communications,  this  transition 
relation  represents  the  different  possible  paths  a  computation  may  take.  The 
processing  of  communications  may,  of  course,  overlap  in  time.  We  represent 
only  the  acceptance  of  a  communication  as  an  event.  Different  transition 
paths  may  be  observed  by  different  viewpoints,  provided  that  these  paths  are 
consistent  with  each  other  (i.e.  do  not  violate  constraints  such  as  causality). 

Definition  1  Possible  Transition.  Let  cj  and  ci  be  two  configurations. 
ci  is  said  to  have  a  possible  transition  to  cj  by  processing  a  task  r,  symboli¬ 
cally,  ci  —*  ct  if  r  €  tasfcs(ci),  and  furthermore,  if  a  is  the  target  of  the 
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of  the  took  then  the  taeke  in  cj  are 

tasks(cj)  =  (tasks(ci)  -  {r})  U  T 

where  T  is  the  set  of  tasks  created  by  a  in  response  to  r,  and  the  actors  in 
C)  are 

actorsfa )  =  (aetors{ei)  -  {a}) U  AU  {a'} 

where  A  are  the  actors  created  by  a  in  response  to  r  and  a1  is  the  replacement 
specified  by  a.  Note  that  a  and  a!  have  the  same  matt  address. 

In  the  actor  model,  the  delivery  of  all  communications  is  guaranteed. 
This  form  of  fairness  can  be  expressed  by  defining  a  second  transition  re¬ 
lation  which  is  based  on  processing  finite  sets  of  tasks  until  a  particular 
task  is  processed,  instead  of  simply  processing  a  single  task  [Agha  84].  A 
denotational  semantics  for  actors  can  be  defined  in  terms  of  the  transition 
relations;  this  semantics  maps  actor  programs  into  the  initial  configuration 
they  define  [Agha  85], 


3  The  Acts  Language 

AetS  is  an  actor-based  programming  language  which  has  been  implemented 
on  the  Apiary  architecture.  The  Apiary  is  a  parallel  architecture  based  on 
a  network  of  Lisp  machines  and  supports  features  such  as  dynamic  load 
balancing,  real-time  garbage  collection,  and  the  mail  system  abstraction 
[Hewitt  80].  Acts  is  a  descendant  of  Acts  [Theriault  83]  and  is  written  in  a 
LISP-based  interface  language  called  Scripter. 

A  program  in  ActS  is  a  collection  of  behavior  definitions  and  commands 
to  create  actors  and  send  communications  to  them.  A  behavior  definition 
consists  of  an  identifier  (by  which  the  actor  may  be  known),  a  list  of  the 
names  of  acquaintances,  and  a  script  (which  defines  the  behavior  of  the  actor 
in  response  to  the  communication  it  accepts).  When  an  actor  is  created  its 
acquaintances  must  be  specified.  For  example,  a  bank-account  actor  may 
have  an  acquaintance  representing  its  current  balance. 

When  a  communication  is  accepted  by  an  actor,  an  environment  is  de¬ 
fined  in  which  the  script  of  the  actor  is  to  be  executed.  The  commands  in 
the  script  of  an  actor  can  be  executed  in  parallel.  Thus  ActS  differs  funda¬ 
mentally  from  programming  languages  based  on  communicating  sequential 
processes  since  the  commands  in  the  body  of  such  processes  must  be  exe¬ 
cuted  sequentially. 
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We  will  first  provide  the  syntax  for  a  kernel  language,  Act,  and  use  it 
to  explain  the  basic  concepts  of  message-passing.  We  then  discuss  some 
extensions  to  Act  which  are  provided  in  ActS.  Finally,  we  illustrate  these 
extensions  by  means  of  examples. 

S.l  The  Kernel  Language  Act 

The  language  Act  is  a  sufficient  kernel  for  the  ActS  language:  all  constructs 
in  the  ActS  language  can  be  translated  into  Act  [Agha  85].  Since  there  are 
so  few  constructs  in  Act,  it  will  be  easier  to  understand  the  primitives  in¬ 
volved  by  studying  Act.  The  acquaintance  list  in  Act  is  specified  by  using 
identifiers  which  match  a  pattern.  The  pattern  provides  for  freedom  from 
positional  correspondence  when  new  actors  are  created.  Patterns  are  used 
in  pattern  matching  to  bind  identifiers,  and  authenticate  and  extract  infor¬ 
mation  from  data  structures.  The  simplest  pattern  is  a  bind  pattern  which 
literally  binds  the  value  of  an  identifier  to  the  value  of  an  expression  in  the 
current  environment.  We  will  not  concern  ourselves  with  other  patterns 
here. 

When  an  actor  accepts  a  communication  it  is  pattern-matched  with  the 
communication  handlers  in  the  actor’s  code  and  dispatched  to  the  handler 
of  the  pattern  it  satisfies.  The  bindings  for  the  communication  list  are  ex¬ 
tracted  by  the  pattern  matching  as  well.  The  syntax  of  behavior  definitions 
in  Act  programs  is  given  below. 


(act  program)  : : » 

(behavior  definition)*  ((command)*) 

(behavior  definition) 

(define  (id  f (with  identifier  (pattern))  }*) 
(communication  handler)*) 

(communication  handler) 

(Is-Communlcation  (pattern)  do  (command)*) 


The  syntax  of  commands  to  create  actors  and  send  communications  is 
the  same  in  actor  definitions  as  their  syntax  at  the  program  level.  There  are 
four  kinds  of  commands;  we  describe  these  in  turn,  send  commands  are  used 
to  send  communications.  The  syntax  of  the  send  command  is  the  keyword 
send  followed  by  two  expressions:  The  two  expressions  are  evaluated;  the 
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first  expression  must  evaluate  to  a  mail  address  while  the  second  may  have 
an  arbitrary  value.  The  result  of  the  send  command  is  to  send  the  value 
of  the  second  expression  to  the  target  specified  by  the  first  expression,  let 
commands  bind  expressions  to  identifiers  in  the  body  of  commands  nested 
within  their  scope.  In  particular,  let  commands  are  used  to  bind  the  mail 
addresses  of  newly  created  actors,  new  expressions  create  new  actors  and 
return  their  mail  address.  A  new  expression  is  given  by  the  keyword  new 
followed  by  an  identifier  representing  a  behavior  definition,  and  a  list  of 
acquaintances. 

The  conditional  command  provides  a  mechanism  for  branching,  and  the 
become  command  specifies  the  replacement  actor.  The  expression  in  the 
become  command  may  be  a  new  expression  in  which  case  the  actor  becomes 
a  forwarding  actor  to  the  actor  created  by  the  new  expression;  in  this  case 
the  two  actors  are  equivalent  in  a  very  strong  sense.  The  expression  can  also 
be  the  mail  address  of  an  existing  actor,  in  which  case  all  communications 
sent  to  the  replaced  actor  are  forwarded  to  the  existing  actor. 

(command)  (let  command)  |  (conditional  command)  | 

(send  command)  |  (become  command) 

(let  command)  flet  ((let  binding)*)  d&  (command)*) 

(conditional  command)  :  :■  (if  (expression) 

(then  do  (command)*) 

(else  do  (command)*)) 

(send  command)  (send  (expression)  (expression)) 

(become  command)  (become  (expression)) 

A  Recursive  Factorial.  We  first  provide  a  simple  factorial  example  to  il¬ 
lustrate  the  use  of  message-passing  in  actors  to  implement  control  structures. 
The  code  makes  the  low  level  detail  in  the  execution  of  an  actor  language 
explicit.  We  will  subsequently  provide  some  higher-level  constructs  which 
will  make  the  expression  of  programs  easier.  The  factorial  actor  creates  cus¬ 
tomers,  called  FactCust,  whose  behavior  is  also  given  below.  Note  that  the 
behavior  of  a  factorial  is  unserialized,  i.e,  it  is  not  history  sensitive. 
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(define  (Factorial (  )) 

(la-Communication  (a  dolt  (with  customer  =m) 

(with  number  =n))  do 

(become  Factorial) 

(11  (NOT  (-  n  0)) 

(then  (send  ml)) 

(else  (let  (x  *  (new  FactCust  (with  customer  m) 

(with  number  n))) 

(send  Factorial  (a  do  (with  customer  x) 

(with  number  n-1)))))))) 

(define  (FactCust  (with  customer  =m) 

(with  number  =n) ) 

(Is-Communication  (a  number  k)  do 
(send  a  n*k) ) ) 

The  acceptance  of  a  communication  containing  an  integer  by  Factorial 
causes  n  to  be  bound  to  the  integer  and  concurrently  for  factorial  to  become 
“itself”  so  that  it  can  immediately  process  another  integer  without  any  in¬ 
teraction  with  the  processing  of  the  integer  it  has  just  received.  When  the 
factorial  actor  processes  a  communication  with  a  non-zero  integer,  n,  it  will : 

•  Create  an  actor  whose  behavior  will  be  to  multiply  n  with  an  integer  it 
receives  and  send  the  reply  to  the  mail  address  to  which  the  factorial 
of  n  was  to  be  sent. 

•  Send  itself  the  “request”  to  evaluate  the  factorial  of  n  —  1  and  send 
the  value  to  the  customer  it  created. 

The  customer  created  by  the  factorial  actor  is  also  an  independent  actor. 
The  work  done  to  compute  a  factorial  is  conceptually  distributed  by  the 
creation  of  the  customer.  In  particular,  this  implies  that  computation  can 
be  speeded-up  if  several  factorials  are  to  be  evaluated  concurrently.  In  the 
case  of  the  factorial,  the  same  result  can  be  obtained  by  multiple  activations 
of  a  given  function.  However,  the  solution  using  multiple  activations  does 
not  work  if  the  behavior  of  an  actor  is  serialized. 


3.2  Functional  Constructs 

In  this  section  we  will  develop  some  notation  for  representing  expressions 
at  a  higher-level.  AetS  provides  many  such  constructs  which  make  ActS 
far  more  expressive  than  Act,  although  the  two  languages  have  the  same 
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expressive  power.  To  allow  functional  programming  without  forcing  the 
programmer  to  explicitly  create  the  customers,  Acts  provides  call  expres¬ 
sions  which  automatically  create  a  customer  and  include  its  mail  address 
in  the  communication  sent;  the  value  of  the  expression  is  returned  (in  a 
message)  to  the  customer  created  at  the  time  of  the  call.  The  code  below 
specifies  a  factorial  actor  in  expressional  terms.  By  comparing  the  code  to 
that  in  the  previous  section,  one  can  see  how  it  is  executed  in  an  actor-based 
environment. 

(define  (call  Factorial  (with  number  =n)) 

(if  («  n  0) 

(then  1) 

(else  (*  n  (call  Factorial  (with  number  n-1)))))) 

Parallel  control  structures  can  also  be  specified  quite  easily.  For  ex¬ 
ample,  a  parallel  algorithm  for  evaluating  the  factorial  function  of  n  is  by 
recursively  subdividing  the  problem  of  computing  the  range  product  from 
1  ton.  We  define  an  actor,  RangeProduct,  for  recursively  computing  the 
range  product  in  the  above  manner.  The  code  for  Rangeproduct  is  given 
below.  Note  that  the  One -Of  construct  provides  a  generalized  conditional 
command:  it  dispatches  on  the  value  of  the  expressions  (cf.  the  guarded 
command  [Dijkstra  76]). 

(define  (call  RangeProduct  (with  low  =lo) 

(with  High  =hi)) 

(One-OT 

(if  (-  lo  hi)  lo) 

(if  (>  lo  hi)  1) 

(i£  «  lo  hi) 

(Let  ((mid  -  (/  (♦  lo  hi)  2))) 

(*  (call  Rangeproduct  (with  low  lo) 

(with  high  mid)) 

(call  Rangeproduct  (with  low  (+  mid  1)) 
(with  high  hi))))))) 


The  pipelining  of  the  replacement  actors  implies  that  two  calls  to  the 
RangeProduct  actor  are  in  fact  equivalent  to  creating  two  actors  which  func¬ 
tion  concurrently.  This  equivalence  follows  from  the  unserialized  nature  of 
the  behavior:  In  case  the  behavior  is  unserialized,  the  behavior  of  the  re¬ 
placement  is  known  immediately  and  thus  its  computation  is  immediate;  in 
particular,  it  can  be  computed  even  before  a  communication  is  received. 
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AetS  provides  a  number  of  other  expressional  constructs,  such  as  delayed 
expressions  and  allows  one  to  require  lazy  or  eager  evaluation  strategies  for 
expressions.  Such  evaluation  strategies  have  been  used  in  extensions  of  pure 
functional  programming  to  model  history-sensitive  behavior  [Henderson  80]. 
However,  because  these  systems  lack  a  mail  address  abstraction,  the  inter¬ 
connection  network  topology  of  processes  is  entirely  static. 

3.3  Modelling  Local-State  Change 

A  problem  with  functional  programming  is  the  difficulty  of  dealing  with 
■hared  objects  which  have  changing  local  states.  Some  constructs,  such 
as  delayed  expressions  have  been  defined  to  model  changing  local  states. 
However,  the  problem  with  these  techniques  is  that  they  create  expressional 
forms  totally  local  to  the  caller  and  thus  can  not  be  used  to  represent  shared 
objects.  Actors  permit  a  graceful  implementation  of  shared  objects  with  a 
changing  local  state.  The  example  below  shows  the  implementation  of  a 
bank  account  in  Acts.  A  bank  account  is  a  canonical  example  of  a  shared 
object  with  a  changing  local  state. 

We  use  the  keyword  Is-Requeat  to  indicate  a  request  communication 
is  expected.  A  request  communication  comes  with  the  mail  address  of  the 
customer  to  which  the  reply  is  to  be  sent.  The  customer  is  used  as  the  target 
of  the  reply.  A  request  also  specifies  a  mail  address  to  which  a  complaint 
can  be  sent,  should  the  request  be  unsuccessful.  From  a  software  point  of 
view,  providing  independent  targets  for  the  complaint  messages  is  extremely 
useful  because  it  allows  the  error-handling  to  be  separated  from  successfully 
completed  transactions. 


(define  (Account  (with  Balance  =b)) 

(Is-Request  (a  Balance)  do  (reply  b)) 

(Is-Request  (a  Deposit  (with  Amount  =a))  do 
(become  (Account  (with  Balance  (+  b  a)))) 

(reply  (a  Deposit-Receipt  (with  Amount  a)))) 
(Is-Request  (a  Withdrawal  (with  Amount  =a))  do 
(if  (>  a  b) 

(then  do  (complain  (an  Overdraft))) 

(else  do 

(become  (Account  (with  Balance  (-  b  a)))) 

(reply  (a  Withdrawal-Receipt  (with  Amount  a))))))) 
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Note  that  the  become  command  is  pipelined  so  that  a  replacement  is 
available  as  soon  as  the  become  command  is  executed.  The  commands  for 
other  actions  are  executed  concurrently  and  do  not  affect  the  replacement 
actor  which  will  be  free  to  accept  further  communications. 

S.4  Transactional  Constructs 

Analyzing  the  behavior  of  a  typical  program  in  terms  of  all  the  transitions  it 
makes  is  not  very  feasible.  In  particular,  the  development  of  debugging  tools 
and  resource  management  techniques  requires  us  to  preserve  the  abstractions 
in  the  source  programs.  Because  actors  may  represent  shared  objects,  it  is 
often  critical  that  transitions  relevant  to  independent  computations  be  kept 
separate.  For  example,  if  the  factorial  actor  we  defined  is  asked  to  evaluate 
the  factorial  of  -1,  it  will  create  an  “infinite  loop.”  Two  observations  should 
be  made  about  such  potentially  infinite  computations.  First,  any  other 
requests  to  the  factorial  will  not  be  affected  because  the  guarantee  of  delivery 
means  that  communications  related  to  those  requests  will  be  interleaved  with 
the  “infinite  loop”  generated  by  the  -1  message.  Second,  in  order  to  keep 
the  performance  of  the  system  from  degrading,  we  must  assess  costs  for  each 
“computation”  independently;  we  can  then  cut-off  those  computations  that 
we  do  not  want  to  support  indefinitely. 

To  formalize  the  notion  of  a  “computation,”  we  define  the  concept  of 
transactions.  Transactions  are  delineated  using  two  specific  kinds  of  com¬ 
munications,  namely,  requests  and  replies.  A  request,  rj,  may  trigger  an¬ 
other  request,  say  rj;  if  the  reply  to  r j  also  precedes  the  reply  to  r\,  then 
the  second  transaction  is  said  to  be  nested  within  the  first.  Proper  nesting 
of  transactions  allows  simpler  resource  management  schemes  since  resources 
can  be  allocated  dynamically  for  the  sub- transaction  directly  from  the  trig¬ 
gering  transaction. 

Transactions  also  permit  the  development  of  debugging  tools  that  al¬ 
low  one  to  examine  a  computation  at  different  levels  of  granularity  [Man¬ 
ning  84].  Various  constructs  in  Acts  permit  proper  nesting  of  transactions; 
for  example,  requests  may  be  buffered  while  simultaneously  preserving  the 
current  state  of  a  server  using  a  construct  called  enqueue.  The  request  is 
subsequently  processed,  when  the  server  is  free  to  do  so,  using  a  dequeue  op¬ 
eration.  Enqueue  and  dequeue  are  useful  for  programming  servers  such  as 
those  controlling  a  hard  copy  device;  they  guarantee  continuous  availability 
[Hewitt  et  al  1984]. 

Independent  transactions  may  affect  each  other;  requests  may  be  sent 
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to  the  same  actor  whoee  behavior  is  history-sensitive  thus  creating  events 
which  are  shared  between  different  transactions.  Such  intersection  of  events 
creates  interesting  problems  for  the  dynamic  allocation  of  resources  and  for 
debugging  tools.  Dynamic  transaction  delimitation  remains  an  exciting  area 
of  research  in  the  actor  paradigm. 


4  Open  Systems 

It  is  reasonable  to  expect  that  large-scale  parallel  systems  will  be  composed 
of  independently  developed  and  maintained  modules.  Such  systems  will  be 
open-ended  and  continually  undergoing  change  [Hewitt  and  de  Jong  85]. 
Actor  languages  are  intended  to  provide  linguistic  support  for  such  open 
systems.  We  will  briefly  outline  some  characteristics  of  open  systems  and 
describe  how  the  actor  model  is  relevant  to  the  problem  of  open  systems. 

4.1  Characteristics  of  Open  Systems 

We  list  three  important  considerations  which  are  relevant  to  any  architec¬ 
ture  supporting  large-scale  parallelism  in  open  systems  [Hewitt  85].  These 
considerations  have  model  theoretic  implications  for  an  algebra  used  to  char¬ 
acterize  the  behavior  of  actors: 

•  Continuous  Availability.  A  system  may  receive  communications  from 
the  external  environment  at  any  point  in  time.  There  is  no  closed- 
world  hypothesis. 

•  Modularity.  The  inner  workings  of  one  subsystem  are  not  available 
to  the  any  other  system;  there  is  an  arms-length  relationship  between 
subsystems.  The  behavior  of  a  system  must  be  characterized  only  in 
terms  of  its  interaction  with  the  outside. 

•  Extensibility.  It  is  possible  for  a  system  to  grow.  In  particular,  it  is 
possible  to  compose  different  systems  in  order  to  define  larger  systems. 

Actors  provide  an  ideal  means  of  realizing  open  systems.  In  the  section 
below,  we  outline  a  model  which  realizes  the  above  characteristics  and,  at 
the  same  time,  abstracts  the  internal  events  in  an  actor  system.  We  thus 
address  the  problem  of  abstraction  in  the  context  of  open  system  modelling. 
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4.3  A  Calculus  of  Configurations 

We  have  described  two  transition  relations  on  configurations  (see  §2.3). 
These  relations  are,  however,  operational  rather  than  extensional  in  nature. 
The  requirements  of  modularity  imply  that  an  abstract  characterization  of 
the  behavior  of  an  actor  system  must  be  in  terms  of  communications  re¬ 
ceived  from  outside  the  system  and  those  sent  to  the  external  actors.  All 
communications  sent  by  actors  within  a  population,  to  other  actors  also 
within  the  population,  are  not  observable  from  the  outside. 

In  the  denotational  semantics  of  sequential  programming  languages,  it  is 
sufficient  to  represent  a  program  by  its  input-output  behavior,  or  more  com¬ 
pletely,  as  a  map  from  an  initial  state  to  a  final  state  (the  so-called  history 
relation).  However,  in  any  program  involving  concurrency  and  nondeter¬ 
minism,  the  history  relation  is  not  a  sufficient  characterization.  Specifically, 
when  two  systems  with  identical  history  relations  are  each  composed  with  an 
identical  system,  the  two  resulting  systems  have  different  history  relations 
[Brock  and  Ackerman  81].  The  reason  for  this  anomaly  is  the  closed-world 
assumption  inherent  in  the  history  relation:  It  ignores  the  possible  interac¬ 
tions  of  the  output  with  the  input  [Agha  85]. 

Instead,  we  represent  the  behavior  of  a  system  taking  into  account  the 
fact  that  communications  may  be  accepted  from  the  outside  at  any  point. 
There  are  three  kinds  of  derivations  from  a  configuration: 

1.  A  configuration  c  is  said  to  have  a  derivation  to  c'  given  an  input  task 
r,  symbolically,  c  ==►  c',  if 

states(c?)  =  etates(c) 

tasks(c')  =  tasks (c)  U  r  A  target(r)  €  population^ ) 

where  states  represents  the  local  states  function  (see  §2.3),  and  tasks 
represents  the  tasks  in  a  configuration.  The  receptionists  remain  the 
same  but  the  external  actors  may  now  include  any  actors  whose  mail 
addresses  have  been  communicated  by  the  communication  accepted. 

2.  A  configuration  c  is  said  to  have  a  derivation  to  c'  producing  an  output 
task  r,  symbolically,  c  ==►  c',  if 

states(d)  =  states(c) 

tasks(c')  =  ta8ks(c)  -  r  A  target(r)  £  population(c) 

where  the  states  and  the  tasks  are  as  above,  and  "  represents  set 
theoretic  difference.  The  external  actors  of  c'  are  the  same  as  those  of 
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e.  The  receptionists  may  now  include  all  actors  whose  mail  addresses 
have  been  communicated  to  the  outside. 

3.  A  configuration  e  has  a  internal  or  silent  derivation  to  a  configuration 
e',  symbolically,  e  =>  c\  if  it  has  a  possible  transition  to  c '  for  some 
task  r  in  c. 

We  can  now  build  a  calculus  of  configurations  by  defining  operations  such 
as  composition,  relabeling  (which  changes  the  mail  addresses),  restriction 
(which  removes  a  receptionist),  etc.  We  give  the  axioms  of  compositionality 
to  illustrate  the  calculus  of  configurations. 

Definition  2  Composition.  Let  ci  ||  cj  represent  the  (concurrent)  com¬ 
position  of  ci  and  cj.  Then  we  have  the  following  rules  of  derivation  about 
the  composition: 

1.  (a)  Let  r  be  a  task  whose  target  is  in  Ci,  then 

+t  /  — t  • 

Cl  ==»  Ct  ,  C2  ==>  c2 
Cl  II  Cj  =&>  c[  II  o', 

(b)  Let  A  be  any  derivation  (input,  output,  or  internal),  provided  that 
if  X  is  an  input  or  output  derivation  then  its  sender  or  target, 
respectively,  is  not  an  actor  in  Ci,  then 


ci  ||  c2  ==>  c\  ||  c2 


2.  The  above  rules  hold,  mutatis  mutandis,  for  C2  ||  cj . 

The  only  behavior  that  can  be  observed  in  a  system  is  represented  by 
the  “labels”  on  the  derivations  from  its  configurations.  These  represent  the 
communications  between  a  system  and  its  external  environment.  Following 
Milner  [80]  we  can  define  an  observation  equivalence  relation  on  configu¬ 
rations.  The  definition  relies  on  equality  of  all  possible  finite  sequences  of 
communications  sent  to  or  received  from  the  external  environment  (ignoring 
all  internal  derivations).  One  way  of  formalizing  observation  equivalence  is 
inductively: 
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Definition  S  Observation  Equivalence.  Let  c\  and  c2  be  any  two  tasks, 
ft  be  either  an  input  or  an  output  task,  g*  represent  any  arbitrary  (finite) 

number  of  internal  transitions,  and  =&  represent  a  sequence  of  internal  tran¬ 
sitions  followed  by  a  ft  transition,  and  furthermore  be  defined  inductively 

as: 


1.  Cl  Mo  Cj 
e.  Cl  W*+1  c,  if 

(a)  V/i(« /  ci  =£=£  cj  then  3e2(ej  =?=£  e2)  A  c'j  c2) 

V/i(i/  cj  =4>  cj  Men  3c2(ci  ==£■  cj)  A  cj  «*  c2) 

i7ow  ci  is  said  to  be  observationally  equivalent  to  cj,  symbolically,  ei  «  cj, 
«/V*(ci  w*  c,). 

The  notion  of  observation  equivalence  is  weaker  than  that  of  the  history 
relation —  it  creates  fewer  equivalence  classes  and  thus  distinguishes  between 
more  configurations.  Specifically,  it  allows  for  distinguishing  between  sys¬ 
tems  that  behave  differently  in  response  to  new  tasks,  after  having  sent  some 
communication  to  an  external  actor. 

We  can  characterize  actor  programs  by  the  equivalence  classes  of  initial 
configurations  they  define.  Properties  of  actor  system  can  be  established  in 
a  framework  not  relying  on  a  closed-world  assumption,  while  at  the  Bame 
time  providing  an  abstract  representation  of  actor  systems  that  does  not 
rely  on  the  internal  details  of  a  systems  behavior. 


5  Conclusions 

Actor  languages  uniformly  use  message-passing  to  spawn  concurrency  and 
are  inherently  parallel.  The  mail  system  abstraction  permits  a  high-level 
mechanism  for  achieving  dynamic  reconfigurability.  The  problem  of  shared 
resources  with  changing  local  state  is  dealt  with  by  providing  an  object- 
oriented  environment  without  the  sequential  bottle-neck  caused  by  assign¬ 
ment  commands.  The  behavior  of  an  actor  is  defined  in  Acts  by  a  script 
which  can  be  abstractly  represented  as  a  mathematical  function.  It  is  our 
claim  that  Acts  has  the  major  advantages  of  object-based  programming 
languages  together  with  those  of  functional  and  applicative  programming 
languages. 
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An  actor  language  also  provides  a  suitable  basis  for  large-scale  paral¬ 
lelism.  Besides  the  ability  to  distribute  the  work  required  in  the  course  of 
a  computation,  actor  systems  can  be  composed  simply  by  passing  messages 
between  them.  The  internal  workings  of  an  actor  system  are  not  available  to 
any  other  system.  A  suitable  model  to  support  the  composition  of  different 
systems  is  obtained  by  composing  the  configurations  they  may  be  in. 
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